Tech Arsenal 1/Tech Arsenal (Arsenal Computer).ISO/tek-20/nosvw.zip/ATTACH

Text File | 1991-09-18 | 26KB | 623 lines

======                                              NOSview [137]
attach
======


This section details the 'attach' commands for the various
hardware and software interface drivers.  Not all of these
drivers may be configured into every NOS release.  A list of the
available types on a particular release may be obtained with the
'attach ?' command.

Some parameters are accepted by several drivers. They are:

---------
<bufsize>
---------
For asynchronous devices (e.g. COM ports operating in SLIP or NRS
mode) this parameter specifies the size of the receiver's ring
buffer.  It should be large enough to hold incoming data at full
line speed for the longest time that the system may be busy in
MS-DOS or the BIOS doing a slow I/O operation (e.g. to a floppy
disk).  A kilobyte is usually more than sufficient.

For synchronous devices (e.g. the scc, hs, pc100, hapn and drsi
interfaces operating in HDLC mode), the <bufsize> parameter
specifies the largest frame that may be received on the
interface.  This should be set by mutual agreement among stations
sharing the channel, and it is important that it is set
correctly.

To do this, you must know the size of the largest possible frame
that can be received.  The AX.25 'paclen' parameter controls only
the size of the data field in an I-frame and not the total size
of the frame as it appears on the air.  The AX.25 specification
allows up to 8 digipeaters, so the largest possible frame is
'paclen'+72 bytes.  You should make <bufsize> at least this
large.

So for standard AX.25 with a maximum I-frame data size of 256
bytes, <bufsize> should be at least 328 (i.e. 256+72).  A
suggested value of 1024 bytes will therefore provide an adequate
safety margin.

On higher speed channels (e.g. 56kb/s) larger values (e.g. 2K
bytes) will provide much better performance and allow full-sized
Ethernet packets to be carried without fragmentation.

Another important consideration is that the more recent versions
of NOS improve interrupt response by maintaining a special pool
of buffers for use by the receive routines.  These buffers are
currently fixed in size to 2048 bytes and this can be changed
only by editing "config.h" and recompiling NOS.

This limits <bufsize>; in fact, attempting to set a larger value
may cause the driver not to work at all.  This situation can be
detected by running the memory status command and looking for a
non-zero count of "Ibuffail" events, although these events can
also occur occasionally during normal operation.


-----------
<interface>
-----------
The name (an arbitrary character string) to be assigned to this
interface. It is used to refer to the interface by many other
commands, including:

        axc25 bc          dialer           rarp
        bbs Gateway       ifconfig         route
        comm              mode             tip
        connect           netrom           trace
        detach            param


-----------
<ioaddress>
-----------
The base address of the interface's control registers, in
hexadecimal.


-----
<mtu>
-----
The Maximum Transmission Unit (MTU) size, in bytes.  Datagrams
larger than this limit will be fragmented at the IP layer into
smaller pieces.

IP-level fragmentation often makes it possible to interconnect
two dissimilar networks, but it is best avoided whenever
possible.  One reason is that when a single IP fragment is lost,
all other fragments belonging to the same datagram are
effectively also lost and the entire datagram must be
retransmitted by the source.

Even without loss, fragments require the allocation of temporary
buffer memory at the destination, and it is never easy to decide
how long to wait for missing fragments before giving up and
discarding those that have already arrived.  A reassembly timer
controls this process.  (See the 'ip rtimer' command).

Most subnetworks that carry IP have MTUs of 576 bytes or more, so
interconnecting them with subnetworks having smaller values can
result in considerable fragmentation.  For this reason, IP
implementors working with links or subnets having unusually small
packet size limits are encouraged to use transparent
fragmentation, that is, to devise schemes to break up large IP
datagrams into a sequence of link or subnet frames that are
immediately reassembled on the other end of the link or subnet
into the original, whole IP datagram without the use of IP-level
fragmentation.

Such a scheme is provided in AX.25 Version 2.1.  It can break a
large IP or NET/ROM datagram into a series of 'paclen' sized
AX.25 segments (not to be confused with TCP segments), one per
AX.25 I-frame, for transmission and reassemble them into a single
datagram at the other end of the link before handing it up to the
IP or NET/ROM module.

The segmentation procedure is a new feature in AX.25 and is
unfortunately not yet widely implemented; in fact, NOS is so far
the only known implementation.  This creates some inter-
operability problems between NOS and non-NOS nodes; in
particular, standard NET/ROM nodes being used to carry IP
datagrams.

For AX.25 UI-frames, MTU limits the size of the information
field.

For AX.25 I-frames, however, the AX.25 'paclen' parameter is also
relevant.  If the datagram or fragment is still larger than
'paclen', it is also fragmented at the AX.25 level (as opposed to
the IP level) before transmission.  See the 'ax25 paclen' command
for further information.

Each fragment of a datagram has its own IP header, and is handled
by the network as if it were a distinct IP datagram.  When it
arrives at the destination it is held by the IP layer until all
the other fragments belonging to the original datagram have
arrived.  Then they are reassembled back into the complete,
original IP datagram.

The minimum acceptable interface MTU is 28 bytes: 20 bytes for
the IP header, plus 8 bytes of data.

There is no default MTU in NOS; it must be explicitly specified
for each interface as part of the 'attach' command.

TCP/IP header overhead considerations similar to those of the
AX.25 layer when setting 'paclen' apply when choosing an MTU.
However, certain subnetwork types supported by NOS have well-
established MTUs, and these should always be used unless you know
what you're doing.  The recommended MTUs for these network types
are:

Ethernet: 1500 bytes
ARCNET:   508 bytes
PPP:      The MTU for PPP is automatically negotiated, and
          defaults to 1500 bytes.

Other subnet types, including SLIP and AX.25, are not as well
standardized.

SLIP:   Has no official MTU, but the most common implementation
(for BSD UNIX) uses an MTU of 1006 bytes.  Although NOS has no
hard-wired limit on the size of a received SLIP frame, this is
not true for other systems.  Interoperability problems may
therefore result if larger MTUs are used in NOS.

AX.25:  Choosing an MTU for an AX.25 interface is more complex.
When the interface operates in datagram (UI-frame) mode, the
'paclen' parameter does not apply.  The MTU effectively becomes
the 'paclen' of the link.  However, as mentioned earlier, large
packets sent on AX.25 connections are automatically segmented
into I-frames no larger than 'paclen' bytes.  Unfortunately, as
also mentioned earlier, NOS is so far the only known
implementation of the new AX.25 segmentation procedure.  This is
fine as long as all of the NET/ROM nodes along a path are running
NOS, but since the main reason NOS supports NET/ROM is to allow
use of existing NET/ROM networks, this is unlikely.

So it is usually important to avoid AX.25 segmentation when
running IP over NET/ROM.  The way to do this is to make sure that
packets larger than 'paclen' are never handed to AX.25.  A
NET/ROM transport header is 5 bytes long and a NET/ROM network
header takes 15 bytes, so 20 bytes must be added to the size of
an IP datagram when figuring the size of the AX.25 I-frame data
field.

If 'paclen' is 256, this leaves 236 bytes for the IP datagram.
This is the default MTU of the "netrom" pseudo-interface, so as
long as 'paclen' is at least 256 bytes, AX.25 segmentation can't
happen.

But if smaller values of 'paclen' are used, the netrom MTU must
also be reduced with the 'ifconfig' command.

On the other hand, if you're running IP directly on top of AX.25,
chances are all of the nodes are running NOS and support AX.25
segmentation.  In this case there is no reason not to use a
larger MTU and let AX.25 segmentation do its thing.  If you
choose an MTU on the order of 1000-1500 bytes, you can largely
avoid IP-level fragmentation and reduce TCP/IP-level header
overhead on file transfers to a very low level.  And you are
still free to pick whatever 'paclen' value is appropriate for the
link.


-------
<speed>
-------
The speed on the NOS serial link (e.g. between the computer
running NOS and the TNC) in bits per second (e.g. 4800).


--------
<vector>
--------
The interface's hardware interrupt (IRQ) vector, in hexadecimal.


The individual 'attach' commands are now described:
_________________________________________________________________
attach 3c500 <ioaddress> <vector> arpa <interface> <qlen> <mtu>
                                                     [<ipaddr>]
_________________________________________________________________
Attach a 3Com 3C501 Ethernet interface.  <qlen> is the maximum
allowable transmit queue length. If the <ipaddr> parameter is not
given, the value associated with a prior ip address command will
be used.

The use of this driver is not recommended; use the 'packet'
driver interface with the loadable 3C501 packet driver instead.

>> Example:  attach 3c500 0x300 3 arpa en0 5 1500


_________________________________________________________________
attach asy <ioaddress> <vector> ax25 | nrs | ppp | slip
             <interface> <buffers> <mtu> <speed> [<slip_options>]
_________________________________________________________________
Attach a standard PC COM port (asynchronous serial port), using
the National 8250 or 16550A chip.  Standard values on the IBM PC
and clones for <ioaddress> and <vector> are as follows:

     COM1:  0x3f8 and 4
     COM2:  0x2f8 and 3

If the port uses a 16550A chip, it will be detected automatically
and the FIFOs enabled.


_________________________________________________________________
attach asy <ioaddress> <vector> ax25 <interface> <buffers> <mtu>
                                                         <speed>
_________________________________________________________________
Encapsulate IP datagrams within an AX.25 frame and precede with a
KISS data header before SLIP encoding.

Either UI- (connectionless) or I- (connection-oriented) AX.25
frames can be used; see the 'mode' command for details.
By default, IP datagrams are sent in UI-frames.

*******  You must give the 'ax25 mycall' command BEFORE attaching
*******  the interface.

>> Example:  To attach the COM2 port to operate in AX.25 mode
with an MTU of 576 bytes at 4800 bits/sec with a KISS TNC,
calling it 'tnc0':

            ax25 mycall NS9BOB-5
            attach asy 0x2f8 3 ax25 tnc0 1024 576 4800


_________________________________________________________________
attach asy <ioaddress> <vector> nrs <interface> <buffers> <mtu>
                                                        <speed>
_________________________________________________________________
Use the NET/ROM asynchronous framing technique for communication
with a local NET/ROM TNC.

>> Example:  attach asy 0x3f8 4 nrs nr0 1024 576 4800


_________________________________________________________________
attach asy <ioaddress> <vector> ppp <interface> <buffers> <mtu>
                                                        <speed>
_________________________________________________________________
Point-to-Point-Protocol.  Encapsulates datagrams in an HDLC-like
frame.  This is a new Internet standard for point-to-point
communication, compatible with CCITT standards.

>> Example:


_________________________________________________________________
attach asy <ioaddress> <vector> slip <interface> <buffers> <mtu>
                                        <speed> [<slip_options>]
_________________________________________________________________
Serial Line Internet Protocol.  Encapsulates IP datagrams
directly in SLIP frames without a link header.  This is for
operation on point-to-point lines and is compatible with 4.2BSD
UNIX SLIP.

The <slip_options> are the characters 'c', 'r' and 'v':

'c' enables RTS/CTS detection
'r' enables RLSD (Carrier Detect) physical line sensing
'v' enables Van Jacobson TCP/IP Header Compression

>> Example:  To attach the COM1 port to operate in point-to-point
slip mode at 9600 baud, calling it 'sl0'.  A 1024-byte receiver
ring buffer is allocated.  Outgoing packets larger than 256 bytes
are fragmented.  RTS/CTS and carrier detection are used, together
with header compression:

           attach asy 0x3f8 4 slip sl0 1024 256 9600 crv


_________________________________________________________________
attach axip <interface> <mtu> <their_host> <my_axip_callsign>
_________________________________________________________________
This creates an RFC1226-compatible AX.25 frame encapsulator for
"wormhole" transmission of AX.25 frames over the Internet.  The
wormhole appears to the AX.25 level as two digipeaters.

The parameter <their_host> is the Internet node name or IP
address of the remote system at the other end of the wormhole.

The parameter <my_axip_callsign> is the AX.25 callsign this
station is listening out for, for frames to digipeat.

Note that each attached axip interface should have a different
callsign to listen to, and this should also be different from
other callsigns used by this station.

For example, consider the scenario in the diagram below.  NS9BOB
and NS9JIM are at opposite ends of an Internet wormhole, in this
case represented by an Ethernet link.  Bob and Jim decide to use
SSID -11 for their axip callsigns.

Stations AX9AAA and AX9BBB are ordinary AX.25 stations which wish
to communicate via the wormhole.



      ___________________                     ___________________
      |                 |                     |                 |
axip: | NS9BOB-11 ....  |                     |  .... NS9JIM-11 |
      |    :         :  |                     |  :         :    |
  IP: | ns9bob       :  |                     |  :       ns9jim |
      |    :         :  |  Internet Wormhole  |  :         :    |
ax25: | NS9BOB-5    en0 ==========>============ en0    NS9JIM-5 |
      |    :            |   AX9AAA>AX9BBB     |            :    |
      |____:____________| v NS9BOB-5* NS9JIM-5|____________:____|
           :tnc0                                       tnc0:
           :                                               :
      _____:____                                       ____:_____
      |        |                                       |        |
      | AX9AAA |                                       | AX9BBB |
      |________|                                       |________|
CONNECT AX9BBB V NS9BOB-11 NS9JIM-5             AX9AAA>AX9BBB
                                           v NS9BOB-5* NS9JIM-11*




To implement this setup, Bob requires the following NOS commands
in his AUTOEXEC.NOS file:

-----------------------------------------------------------------
ax25 mycall NS9BOB-5
attach asy 0x3f8 4 ax25 tnc0 1024 576 4800
ip address ns9bob
route add ns9jim en0
arp add ns9jim ether 00:11:22:33:44:55
attach axip ai0 256 ns9jim NS9BOB-11
-----------------------------------------------------------------

That is, in addition to the usual commands for setting up the
tnc0 AX.25 interface, an IP 'route' command and an 'arp add'
command are needed for the Ethernet wormhole, and the 'attach
axip' command is required to implement AX.25 encapsulation.

Note that in Bob's 'attach axip' command, the hostname (ns9jim)
is the name of the FAR end of the wormhole, and the axip callsign
(NS9BOB-11) is that of the LOCAL station.

Jim's NOS entries will, of course, be a mirror image of Bob's.

Everything is now ready for AX9AAA to connect to AX9BBB.  The
format of the connect command is:

-----------------------------------------------------------------
CONNECT <destination> VIA <local_axip_call> <remote_ax25_mycall>
-----------------------------------------------------------------

Thus in this scenario, AX9AAA gives the command:

    CONNECT AX9BBB VIA NS9BOB-11 NS9JIM-5

NS9BOB is listening for digipeater callsign NS9BOB-11.  On
hearing this connect request, the axip code then converts NS9BOB-
11 to NS9BOB-5.  This is in readiness for the return trip.  In
addition, the "Has-been-digipeated" bit (indicated by an asterisk
in the diagram) is set.

The frame is then encapsulated in an IP packet and transmitted
across the wormhole to Jim.

On arrival at NS9JIM, the axip code now de-capsulates the AX.25
frame, and converts the second digipeater address (NS9JIM-5) to
NS9JIM-11, also setting the "Has-been-digipeated" bit.

Finally the AX.25 frame emerges from NS9JIM, and arrives at
AX9BBB with digipeater addresses NS9BOB-5 and NS9JIM-11.  After
reversing the callsign order in the usual way, this is exactly
what is required for the return trip to AX9AAA via the wormhole.


_________________________________________________________________
attach drsi <ioaddress> <vector> ax25 <interface> <bufsize> <mtu>
                                     <ch_a_speed> <ch_b_speed>
_________________________________________________________________
N6TTO driver for the Digital Radio Systems PCPA 8530 card.  Since
there are two channels on the board, two interfaces are attached.
They will be named <interface> with 'a' and 'b' appended.

<bufsize> is the receiver buffer size in bytes; it must be larger
than the largest frame to be received.

<ch_a_speed> and <ch_b_speed> are the speeds, in bits/sec, for
the A and B channels respectively.


_________________________________________________________________
attach eagle <ioaddress> <vector> ax25 <interface> <bufsize>
                                               <mtu> <speed>
_________________________________________________________________
WA3CVG/NG6Q driver for the Eagle Computer card (Zilog 8530).


_________________________________________________________________
attach hapn <ioaddress> <vector> ax25 <interface> <bufsize> <mtu>
                                                   csma | full
_________________________________________________________________
KE3Z driver for the Hamilton Amateur Packet Network adapter
(Intel 8273).  The 'csma|full' parameter specifies whether the
port should operate in carrier sense multiple access (CSMA) mode
or in full duplex.


_________________________________________________________________
attach hs <ioaddress> <vector> ax25 <interface> <bufsize> <mtu>
                                      <key_up_delay> <p>
_________________________________________________________________
Attach a DRSI PCPA or Eagle Computer interface card using a
special "high speed" 8530 driver.  This driver uses busy-wait
loops to send and receive each byte instead of interrupts, making
it usable with high speed modems (such as the WA4DSY 56kb/s
modem) on slow systems.  This does have the side effect of
"freezing" the system whenever the modem transmitter or receiver
is active.

This driver can operate only in CSMA mode, and it is recommended
that no other interfaces requiring small interrupt latencies be
attached to the same machine.

The <key_up_delay> parameter specifies the transmitter keyup
delay in byte time intervals.

The <p> value specifies the transmitter persistence value in the
range 1-255; the corresponding slot time is fixed at one hardware
clock tick, about 55 ms on the PC.

As with the other 8530 drivers, this driver actually attaches two
interfaces, one for each 8530 channel.


_________________________________________________________________
attach kiss <existing_asy_interface> <port> <interface> [<mtu>]
_________________________________________________________________
The 'attach kiss' command enables a multiplexed TNC type to be
used for second channel.  It is used to connect a second port to
an already attached 'asy' interface.  It will copy most of the
parameters of its parent port.

>> Example:  attach kiss tnc0 2 tnc1


_________________________________________________________________
attach netrom
_________________________________________________________________
Pseudo-driver for use with NET/ROM.


_________________________________________________________________
attach packet <vector> <interface> <txqlen> <mtu>
_________________________________________________________________
Driver for use with separate software packet drivers meeting the
Packet Driver specification from FTP Software Inc.  The driver
must have already been installed before the 'attach' command is
given.  Packet drivers in the Ethernet, ARCNET, SLIP, SLFP, and
KISS/AX.25 classes are supported.

<vector> is the software interrupt vector used for communication
to the packet driver, and <txqlen> is the maximum number of
packets that will be allowed on the transmit queue.

>> Example:  In AUTOEXEC.BAT, the driver for a Western Digital
WD8003E Ethernet adapter can be installed with the command:

     WD8003E 0x60 2 0x240 0xd000

This means that the adapter uses software interrupt vector 0x60,
IRQ 2, I/O address 0x240 and RAM base address 0xd000.

Then the NOS packet driver can be attached to the adapter driver
with the command:

     attach packet 0x60 en0 8 1500


_________________________________________________________________
attach pc100 <ioaddress> <vector> ax25 <interface> <bufsize>
                                                          <speed>
_________________________________________________________________
Driver for the PACCOMM PC-100 (Zilog 8530) card.  Only AX.25
operation is supported.


_________________________________________________________________
attach pi
_________________________________________________________________
DMA-driven 8530 scc board from VE3IFB.


_________________________________________________________________
attach scc <devices> init <addr> <spacing> <Aoff> <Boff><Dataoff>
          <intack> <vec> [p|r]<clock> [<hardware_type>] [<param>]
_________________________________________________________________
PE1CHL driver to initialize a generic SCC (8530) interface board
prior to actually attaching it.

The parameters are as follows:

<devices> The number of SCC chips to support.

<addr> The base address of the first SCC chip (hex).

<spacing> The spacing between the SCC chip base addresses.

<Aoff> The offset from a chip's base address to its channel A
control register.

<Boff> The offset from a chip's base address to its channel B
control register.

<Dataoff> The offset from each channel's control register to its
data register.

<intack> The address of the INTACK/Read Vector port.  If none,
specify '0' to read from RR3A/RR2B.

<vec> The CPU interrupt vector for all connected SCCs.

<clock> The clock frequency (PCLK/RTxC) of all SCCs in hertz.
Prefix with 'p' for PCLK, 'r' for RTxC clock (for baudrate
generation).

<hardware_type>  Optional hardware type code.  The following
values are currently supported:
          1:  Eagle card
          2:  PACCOMM PC-100
          4:  PRIMUS-PC card (DG9BL)
          8:  DRSI PCPA card.

<param> Optional extra parameter.  At present, this is used only
with the PC-100 and PRIMUS-PC cards to set the modem mode.  The
value 0x22 is used with the PC-100 and 0x2 is used with the
PRIMUS-PC card.

The 'attach scc ... init' command must be given before the
interfaces are actually attached with the following command.

_________________________________________________________________
attach scc <chan> slip|kiss|nrs|ax25 <interface> <mtu> <speed>
                                           <bufsize> [<callsign>]
_________________________________________________________________
Attach an initialized SCC port to the system.  The parameters are
as follows:

<chan> The SCC channel number to attach, 0 or 1 for the first
chip's A or B port, 2 or 3 for the second chip's A or B port,
etc.

slip | kiss | nrs | ax25
The operating mode of the interface.  'slip', 'kiss' and 'nrs'
all operate the port hardware in asynchronous mode:
  'slip' is Internet-standard serial line IP mode.
  'kiss' generates SLIP frames containing KISS TNC commands and
AX.25 packets.
  'nrs' uses NET/ROM local serial link framing conventions to
carry NET/ROM packets.
  'ax25' puts the interface into synchronous HDLC mode that is
suitable for direct connection to a half duplex radio modem.

<speed> The interface speed in bits per second (e.g. 1200).
Prefix with 'd' when an external divider is available to generate
the TX clock.  When the clock source is PCLK, this can be a /32
divider between TRxC and RTxC.  When the clock is at RTxC, the TX
rate must be supplied at TRxC.  This is needed only for full
duplex synchronous operation.  When this arg is given as 'ext',
the transmit and receive clocks are external, and the internal
baud rate generator (BRG) and digital phase locked loop (DPLL)
are not used.


_________________________________________________________________
attach slfp
_________________________________________________________________
Attach the Serial Line Framing Protocol packet driver.